Over the weekend, I uploaded some IR-only device CCFs for the following 7 devices:

Lutron Lighting System
Marantz VP-12S1 DLP Projector
Marantz DV-18mkII DVD Player
ProScan PSHD-105 DSS/HDTV Receiver
RCA DTC 100 DSS/HDTV Receiver
Sony SLV-R1000 SVHS VCR
Sunfire Theater Grand II Processor

You can find them in their respective categories in the files ares.

I used a format for these CCFs that we've discussed in here as the best way to do them, but I took the idea a bit further and wanted to suggest a specific format for those of you who are uploading this type of IR-only device CCFs. I've dubbed it "JETI" format - for Jenkins Easy To Import format.

CCFs in this format are designed to be easy to import into a new or existing CCF, hidden, and then aliased from custom panels and/or referenced in macros. JETI format is perfect for CCF programmers who like to tinker with their layout, because all the IR codes remain nice and intact in their own hidden panels.

Here are the required elements for my JETI Format:

1. All codes must be clean. This is important to keep file size down, and to make functionality predictable. Some dirty codes can repeat and create undesired results when running on newer (and faster) firmware.

2. All codes must be verified. Each IR code must be tested on the device to make sure it does what it's supposed to.

3. All codes must be properly labeled. This means that "internal" code label for learned codes shows the device type and the function (such as VCR - Fast Forward) instead of just LEARNED. This helps with aliasing later on. Proper labeling also means that the button on the panel is text only. Button BMP icons should only be used on the custom panels that will be seen by the user. JETI panels are designed to be hidden, so icons on the buttons only take up extra memory.

4. All IR codes must be stored on the minimum number of panels possible. In most cases, all the IR codes for the device are on one panel, but for devices with lots of codes, they have been split into two panels and labelled accordingly. This allows for easy aliasing from custom panels and hard buttons, and/or inclusion in macros.

5. Device-specific bitmap graphics are included on one or more separate panels. These include brand or technology logos, icons of the device itself, etc. These can be used in custom CCF layouts, or simply deleted if not used by the programmer.

6. All panels fit inside the 240 x 219 panel size so that they can be imported into any compatible unit. Some of the IR codes that had to be split across two panels could have been combined into one panel of 240 x 270, but those could only have been imported into the RC5200 and RC9200.

7. All additional properties, devices, panels, hard button settings, etc. must be blank. This allows the JETI format CCF to be merged with an existing CCF without overwriting any settings or creating additional memory overhead.

There you have it! I invite other uploaders to adopt this format to make things easy for custom CCF developers. All my future uploads will be in JETI format. And I'd also like to invite those who upload custom CCFs with device interface panels (you know - the pretty ones with the graphics) to incorporate these types of hidden aliasing panels in your complete device CCFs so that editing your custom interface panels is easier.

I welcome your feedback and suggestions!

Thanks,

Steve Jenkins

Sounds like you have a lot of time on your hands. :)

Good idea and it makes a lot of sense . . . but until someone comes up with some sort of a FORM that will constrain submissions to a particular form-factor, I think there's just too much diversity in the way people design and use their CCFs.

Again . . . Good Idea, but this ain't a perfect world full of good little soldiers.


    MIKE

I have a suggestion, why dosen't everyone just submit a basic simple button code alias page for devices. I don't really care how you like to layout your buttons, I'll do it the way I like with the bitmaps I like. I just want your codes. Simple as that. Just a bunch of square buttons with clean codes is just fine with me.

Matt - I agree completely! And that's exactly what I'm suggesting with this format! All codes on one panel with no graphics in little boxes crammed next to each other so that you can alias your own custom panels as you like.

Mike:

Oh, I know. It's wishful thinking to believe that everyone will automatically comply with this. I was simply stating that I plan to follow this format with all IR code panels I submit, and that others who want to help out by submitting panels can dramatically increase their helpfulness by playing along with me :) It's a grass-roots voluntary thing, man :)

Steve

Well, I'll submit all my alias pages this way. It's much easier for everyone really. I think the entire database would be much easier to use this way.

I don't even really care how many buttons are on these pages, just square boxes with the clean codes. I think mine are 4X7. Makes a neat appearance but yet totally functional.

Ahhhh, yes. The groundswell of support begins.... :)

But there is also another way to look at the variety of submissions.

It is a great teaching tool, trying to figure out all the various ways people configure things. It's possibly as much a positive as it is a negative, at least in my book.
I know I learned A Whole LOT just by the trial & error (and error, and error) method in taking apart many of the other CCFs I used as reference in making my own CCF.

I'm not against this (or your effort), Steve. Let's just say I like playing the Devil's Advocate occasionally. (Oh, OK! Maybe not so occasionally. ;-p ).

    MIKE

Yeah, but then download the entire CCF from that area. Not the Device area.

The only way for this to work is if Daniel Tonks insists that all ccf component files are submitted in a certain format.

I agree that when I am downloading specific device codes for my own ccf. I don't really care for other people's complete system ccf with large word document with graphics on the concepts and theories behind the design. I also don't want the 'other' verions of the ccf and the gallery file that comes free with the zip file.

However, when I submitted my device ccf for my DVD player I simply deleted all other items in my ccf and submitted the file to this website.
If Daniel had insisted that I re-format the file then it would have probably dropped to the bottom of my ToDo list and may still be there.

It would be good ( and perhaps should be common knowledge that we prefer) for device ccf's to take as little time as possible to download so for politeness device ccf's should contain no graphics and simply the core details (leave that up to the programmer to define) and people who submit slow/large ccf's should be reminded how inconvienient (unpolite) their ccf is.

On the other hand, system CCFs should be HUGE and take blooming ages to download but WOW the user !

Well... don't forget that 90% of the "device" CCFs that are out there are only there because someone uploaded their System CCF. I keep thinking, "Hey, I oughtta spliut my CCF into single devices and upload somthing simple with just the codes. But then, that doesn't do ME any personal good, so I get lazy, and I never get around to it.

I guess what I'm saying is that I don't think anyone is being rude because their system CCF is linked to a component CCF download. We didn't choose the format of the web page, and in most cases, we didn't submit our CCFs as component CCFs in the first place.

Other than that, yes, I think it would be great if the component CCFs all used a common format, and even a common simple graphics style. I doubt it will happen... but it would be great.

Dale

I'm in violent agreement with nearly all the comments so far, and again want to re-iterate that I'm not trying to be the Code Nazi, I'm just trying to convince others who upload component (aka device) CCFs to take a few extra steps to make them much more useful to the rest of us who download stuff from this great site. This should never be a compulsory thing, but it would be great if perhaps Daniel could add some sort of labeling mechanism to the Component CCFs that DO follow this format. Or make the CCFs in this format a sub-set of the Component CCF listings. He's welcome to steal my "JETI" name if he wants ;)

And I'm sure Daniel just LOVES it when we suggest extra work for him ;)

I agree with all that was said above, even if some seem contradictory :-)

1) IR code pages are useful if you are just looking for the codes

2) Complete CCFs and partial CCFs can be useful since there can be hints i.e. we all know older Toshiba TVs did not have discrete codes for inputs but that there is a workaround. A newby can find the trick by looking at the CCF (like Mike said, there is a lot to learn from complete CCFs)

3) Like I have said many times before, component CCFs just means that the CCFs are classified by components, so you will always have complete CCFs

4) When you need a device, it does not matter in what fashion it comes in, but if you are using IR code pages, then it is not all that much work to subdivide it

5) I agree smaller CCFs would be faster downloads, but then again a complete CCF does not take that log to begin with.

6) don't forget that just because we have an interface that we use, that others might not be looking for one.

Perhaps people might just use a common format if the file area listed the component files in a way that clearly indicated that they were, or were not, in the "agreed upon format."

If there were a download area for "Component Files in Remote Central Format," then you'd know if you were getting the "clean" version. This would allow a single "authority" to set the standard format, thereby avoiding the chaos that would certainly ensue if the format were just an evolving concept among strangers.

If there were such a standard, and a compelling reason to comply with it, I think I would probably upload my stuff in the "correct" format.


Dale